HIMEM is supposed to set the highest address BASIC can use, right? Well, it goes over that! I am writing a shape table generator and I want everything to be under $4000--the end of the high resolution graphics memory, so that everything that will be available for a shape table will be available to my utility. So I use a HIMEM: 16384 (16382 to be safe), but BASIC zeroes out the first 50-80 bytes or so of my table which starts at $4000. I know it generates the table correctly because it comes out fine when I test it with the tables starting higher up in memory, but that is not an acceptable long-term solution. Does anyone know of anything that could be causing this, or any alternative methods to safeguarding memory?
Path: BASIC/HIMEM problems...
Subj: Two things... 90-09-22 12:40:56 EST
From: AFA Gary J
Posted on: America Online
First of all, BASIC programming under ProDOS requires that HIMEM be set on page bounderies, that is, in multiples of 256 ($100) bytes. So, your setting HIMEM to 16384 would be correct, and not 16382. This isn't what's causing your problem, however.
What IS causing your problem (in my guess) is that ProDOS always tries to allocate a 1K buffer just above HIMEM for use with cataloging, and what not. With no files open, set HIMEM to the value you want (making sure it's a multple of 256), and place your data starting 1K above HIMEM. Check out the ProDOS 8 Technical Reference Manual for more information, including memory maps.
Gary
Path: BASIC/HIMEM problems...
Subj: Thanks 90-09-22 15:08:06 EST
From: Mick B
Posted on: America Online
for the prompt reply. I hope it works!
Path: BASIC/HIMEM problems...
Subj: But also... 90-09-22 15:54:13 EST
From: Eight bits
Posted on: America Online
There is another problem. Because you are using hi-res graphics, you not only have to reserve a safe place for your table, but you must also avoid memory conflicts within Basic itself. Remember, Basic stores its strings beginning just below HIMEM and extending downward in memory. If you set HIMEM to $4000, the strings will get stored in the graphics display area and you will eventually crash. The problem with setting HIMEM "a little higher" than $4000 is that Basic still won't protect the strings - if you keep creating them they will eventually drift down into the display screen. You can manage them yourself with FRE commands, but I think it's easier not to change HIMEM at all. Consider instead a line like:
10 LOMEM: 6 * 4096
as the very first line of your program. Memory will now look like this:
$801-$1FFF - available for your program code
$2000-$3FFF - hi-res graphics screen page 1
$4000-$5FFF - a safe 8K area for tables, m/l programs, etc
$6000-HIMEM - Basic variable storage.
This is for LOMEM set at $6000. You could use another value depending on the size of your table, whether or not you use the 2nd graphics screen, etc. Again, though, the LOMEM command should be the very first line of the program, and shouldn't be used again after this.
You also must avoid a conflict at the =bottom= of the graphics screen. Remember that any program which uses page 1 of hi-res graphics must fit below $2000. A program less than 13 blocks long should be safe. There are other ways to deal with larger programs.
